1. Technical Field
The invention relates to PostScript® Printer Description (PPD) files and more particularly to computer processes and systems for generating PPD files for printers.
2. Description of the Prior Art
A PostScript® Printer Description (PPD) file is a text file that describes the printer features unique to particular printers in particular environments to the PostScript® Printer Driver(s) available for that environment. Ubiquitous PostScript® printer driver executable program files are used to provide communications between an application program and PostScript®-enabled printers residing on the network. Each PPD file contains certain phrases that describe what a particular printer is capable of doing. PPD files are commonly created by manufacturers of PostScript® printers. The driver is created either by Adobe Systems, Inc., the creators of PostScript® language, or by provider of the particular operating system the user is using (whether it be Microsoft corporation in case of Windows or Apple Computers in case of Macintosh), or it is sometimes provided by manufacturers of different application programs that a user may be using.
A PPD file is not a printer driver. It is an information file, in ASCII format, that is used by a printer driver loaded by an operating system or application program. Because PPDs are all written in ASCII-text format, they are not limited to a specific software environment or platform. An ASCII-text PPD file can therefore be used equally well in Windows, MAC-OS, and UNIX environments, and by a variety of software applications, Adobe Systems, Inc. (Sunnyvale, Calif.) has defined how PPD files must be constructed by printer and software vendors in the “PPD Specification,” now at version 4.3.
In general, a PPD file contains information that describe the capabilities of a particular printer to a printer driver. The driver then communicates some of this information to the end-user and allows him to choose certain features suited to the file being printed. For example, if the printer in question is color capable, has duplexing (ability to print to both sides of the page), and supports paper sizes Letter, Legal, and Tabloid, then printer drivers having access to this PPD are capable of providing this information to user using common user interface features such as popup menus and radio buttons. The user then selects a combination of the features available on that particular printer to be used when the data is at some point being printed. For example, a user may choose to print a certain word processing document to a letter-size page in back and white mode while the same or another user may decide to print another file containing graphics to a tabloid-size page in color.
It is an unfortunate fact for the manufacturer of PPDs that all PostScript printer drivers that claim to conform to the Adobe PPD Specifications often do not behave in exact manners when using a PPD. There are several gray area situations in which a PPD file that works correctly for one printer driver, may fail in part when used by another driver. As a result, a manufacturer of PPDs has to provide several PPD files that are each suited for a particular environment so that a majority of potential users can take advantage of their benefits. One such situation arises with PPD files for languages other than English. Since PPD files contain strings used in user-interface dialogs, these strings need to be translated for all supported languages. The way different drivers interpret non-English characters, such as “graves”, “acutes” and “umlates”, are different on different platforms. So a French PPD for the Macintosh platform is different than a PPD for Windows 3.1 at least when it comes to these strings. These PPDs may also be different due to technical reasons determined by the printer/PPD miter. For example, the manufacturer may decide that a certain feature is to be supported only on Windows 95/98 platforms but not on Windows NT.
The conventional method of generating PPD files for different platforms and languages involves a significant amount of manual typing or “copy and paste” operations. This is an overwhelming task. Let us assume that at some point during the development of a printer, an engineer working for the printer manufacturing company is assigned the task of adding support for a new pagesize, A4, to all the PPDs pertaining to that product. The challenge is two-fold. First of all, he must come up with the ASCII text segments that must be added or changed in the existing PPD. Secondly, he must make these changes to every PPD the company is shipping for that printer. If the product line supports three languages and four platforms, he is faced with the daunting task of editing twelve (3 languages×4 platforms) files. The conventional method, therefore, can be described as time-consuming and prone to human errors as each revision for a language-platform combination is constructed.
It would be advantageous to provide a system that generates all the necessary PPD files for all platforms and languages from a single source.